Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propose a Scheduled condition for RB/CRB #823

Merged
merged 2 commits into from
Oct 18, 2021

Conversation

dddddai
Copy link
Member

@dddddai dddddai commented Oct 16, 2021

What type of PR is this?
/kind feature

What this PR does / why we need it:
Please refer to #821 (comment)

Which issue(s) this PR fixes:
Fixes #821

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

@karmada-bot karmada-bot added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 16, 2021
@karmada-bot karmada-bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Oct 16, 2021
Comment on lines 937 to 955
// setScheduledCondition sets the Scheduled condition for the given binding
func setScheduledCondition(status *workv1alpha2.ResourceBindingStatus, scheduled metav1.ConditionStatus, scheduleType ScheduleType) {
newScheduledCondition := metav1.Condition{
Type: workv1alpha2.Scheduled,
Status: scheduled,
Reason: string(scheduleType),
LastTransitionTime: metav1.Now(),
}

meta.SetStatusCondition(&status.Conditions, newScheduledCondition)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would we distinguish the schedule type here?
The lastTransitionTime is the last time the condition transitioned from <none> status to 'Scheduled'.
The condition should not change from Scheduled(first schedule) to Scheduled(reconcile schedule).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RainbowMango Thanks for your review!

Why would we distinguish the schedule type here?

I just tried to figure out a good condition reason and used schedule type as the reason

The condition should not change from Scheduled(first schedule) to Scheduled(reconcile schedule).

Why? Do you mean the reason should be a constant string? Sorry I didn't get the point, please correct me if I'm wrong

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think The Scheduled condition represents if an RB has been scheduled or not, actually we don't care the reason(at least for now). And the lastTransitionTime is basically the scheduled time.

Copy link
Member

@RainbowMango RainbowMango left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So quick!
Appreciate!

@dddddai dddddai force-pushed the sched-condition branch 5 times, most recently from d4076f4 to 37b3b67 Compare October 16, 2021 11:54
Comment on lines 483 to 484
setScheduledCondition(&binding.Status, metav1.ConditionTrue, scheduleSuccessReason, scheduleSuccessMessage)
_, err = s.KarmadaClient.WorkV1alpha2().ResourceBindings(binding.Namespace).UpdateStatus(context.TODO(), binding, metav1.UpdateOptions{})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a question, if the condition already exists, can we ignore the update here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yes, sorry for my oversight, fixed

@RainbowMango
Copy link
Member

/assign @XiShanYongYe-Chang

Copy link
Member

@RainbowMango RainbowMango left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Glad to see that you added the E2E test.
/approve
leave LGTM to @XiShanYongYe-Chang for the E2E test part.

Copy link
Member

@XiShanYongYe-Chang XiShanYongYe-Chang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's generally fine, some suggestions can be considered.

pkg/scheduler/scheduler.go Outdated Show resolved Hide resolved
pkg/scheduler/scheduler.go Show resolved Hide resolved
pkg/scheduler/scheduler.go Show resolved Hide resolved
@@ -152,6 +152,15 @@ var _ = ginkgo.Describe("failover testing", func() {
fmt.Printf("reschedule in %d target cluster\n", totalNum)
})

ginkgo.By("check if the scheduled condition is true", func() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is unnecessary to add this judgment to determine the conition of binding.

If the condition Scheduled is not set to true, the resource will not be propagated to member clusters and the previous test will fail. Same as bellow.

How do you think?

Copy link
Member Author

@dddddai dddddai Oct 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@XiShanYongYe-Chang Thanks for your review!
Yes it seems unnecessary now, but it can make sure the scheduled condition is True if any changes are made in future, in which case this test should work.

From this point of view, the test is reasonable, so I'm inclined to keep it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok.

Copy link
Member

@XiShanYongYe-Chang XiShanYongYe-Chang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reserve E2E, some nits, other lgtm.

Comment on lines 156 to 157
rb, err := getResourceBinding(deployment)
gomega.Expect(err).ShouldNot(gomega.HaveOccurred())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to put this logic into PollImmediate function, otherwise will judge the same rb until timeout.

Same as other parts.


// get the resource binding associated with the workload
func getResourceBinding(workload interface{}) (*workv1alpha2.ResourceBinding, error) {
uncastObj, _ := runtime.DefaultUnstructuredConverter.ToUnstructured(workload)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add err judgement:

uncastObj, err := runtime.DefaultUnstructuredConverter.ToUnstructured(workload)
gomega.Expect(err).ShouldNot(gomega.HaveOccurred())

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for reminding, fixed, PTAL:)

Copy link
Member

@XiShanYongYe-Chang XiShanYongYe-Chang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you.

/lgtm

@karmada-bot karmada-bot added the lgtm Indicates that a PR is ready to be merged. label Oct 18, 2021
@RainbowMango RainbowMango added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 18, 2021
@karmada-bot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

This pull-request has been approved by: RainbowMango

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@karmada-bot karmada-bot merged commit d2af1e1 into karmada-io:master Oct 18, 2021
@dddddai dddddai deleted the sched-condition branch October 24, 2021 02:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/feature Categorizes issue or PR as related to a new feature. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature: Propose a Scheduled condition for RB/CRB
4 participants